BlueOnyx 5212R Released
We are proud to announce the immediate release of BlueOnyx 5212R.
Back in November 2024 RedHat released the RHEL10 Beta and that gave us some ideas of what to expect for RHEL10 (and clones). This also started preliminary groundwork of getting the BlueOnyx GUI ready to work with the PHP version expected to be the default on EL10.
Once that was done we decided to wait for the release of AlmaLinux 10 or RockyLinux 10 (whichever was out first) before any real development was carried out. Otherwise it would be an endless quest to chase dependencies which never are present in any of the BETAs. AlmaLinux 10 was released on the 27th of May 2025 and shorty after that we created the necessary build environment for BlueOnyx 5212R on a naked AlmaLinux 10 VM. After a month of dependency chasing and building a basic BlueOnyx 5212R was up and running. And then we invested another month into fixes, general improvements and thorough testing.
Lastly: Over the weekend installation media (ISOs and Incus/LXC images) have been built and tested and with that out of the way it is now time for a general release of BlueOnyx 5212R.
Downloads
Differences between 5212R and its predecessor 5211R:
Let us start with some changes on the OS level: RedHat decided to optimize the OS for newer CPU architectures and deprecated a whole heap of older architectures, chipsets and drivers. RHEL10 now requires CPUs with at least the x86_64_v3 feature set. It was introduced to allow distributions and applications to be optimized for CPUs released around 2011 or later, notably:
- Intel: Sandy Bridge and newer
- AMD: Bulldozer and newer
Software compiled for x86_64_v3 won’t run on older CPUs lacking these features. BlueOnyx 5212R requires x86_64_v3 (or newer).
How to find out if your server supports x86_64_v3:
lscpu | grep -E 'sse4_2|popcnt|cx16|lahf_lm'Or:
cpuid | grep -i -E 'sse4_2|popcnt|cx16|lahf_lm'If this returns results, then you're covered.
Please note: We are aware that AlmaLinux ships a (separate) version of AlmaLinux 10 that is explicitly x86_64_v2 compatible. While we laude and applause their effort? This is essentially a separate distribution. It has its own (separate) DNF repositories as code built on x86_64_v3 cannot run on x86_64_v2 and vice versa. We debated internally if we would use x86_64_v3 or x86_64_v2 for BlueOnyx 5212R or would release BlueOnyx for both. But it is twice the work and twice the long term maintenance for next to no gain. x86_64_v3 came out in 2011 and if someone really wants to run BlueOnyx on ancient hardware, then there is still BlueOnyx 5211R around which can be used there. Hence we chose to embrace modernity and BlueOnyx 5212R requires x86_64_v3 (or better).
What else is new in BlueOnyx 5212R:
- PHP: v8.3.19
- MariaDB: v10.11.11
- Apache: v2.4.63
- Postfix: v3.8.5
- Sendmail: v8.18.1 (*)
- Dovecot: v2.3.21
- ProFTPd: v1.3.9
- Radicale: v3.5.4
- GUI integrated FTP via elFinder v2.1.65
- GUI integrated phpMyAdmin v5.2.2
- GUI integrated Shellinabox v2.21
- GUI integrated GoAccess v1.9.4
Let's talk about some of these.
YUM/DNF:
The "yum" command has been deprecated. You have to use "dnf" now. The syntax is the same, so you will feel right at home.
PHP:
The OS provides PHP-8.3.19 and as before on older BlueOnyx versions the AdmServ that runs the GUI brings its own PHP (at this time: v8.3.23) with it. At this time the following PHP packages are available via NewLinQ in the BlueOnyx shop:
As usual we tried to provide a selection of end-of-life (EOL) versions of PHP as well in order to make transition to BlueOnyx 5212R easier. Generally the usage of EOL versions of PHP is discouraged for security reasons, but there is a need and demand for it. So we tried to go as far back with PHP versions as possible. And that turned out to be PHP-7.3.33.
Postfix / Sendmail:
Those of you in the know what RHEL10 (and clones) contain will probably wonder why Sendmail is still present on BlueOnyx 5212R. Because RedHat deprecated it and removed it from the OS. BlueOnyx (since 5210R) uses Postfix as default MTA, but as you might be aware: The GUI still builds the Sendmail configuration and our Postfix then imports these on the fly whenever it is restarted. The guys over at EPEL were so kind to release a maintained version of Sendmail for EL10, so this is why we chose to integrate it into BlueOnyx 5212R - even though the OS usually doesn't have it anymore. The included Sendmail is fully usable, but you should leave the MTA configured to use Postfix instead.
The rest of the libraries and services hold no surprises and are present in sightly more modern versions than on EL9 and older BlueOnyx versions.
The new BlueOnyx 5212R GUI
It looks the same as before, right? Yeah, but under the hood a lot is new. We spent a month of around the clock work (weekends included) to improve the GUI, address nuisances and tweak functionality to the max.
The new BlueOnyx GUI uses the latest CodeIgniter 4.5, brings its own PHP-8.3.23 aboard (installed in /home/solarspeed/admserv-php/) and uses our new CCEd-API v2. AdmServ (with HTTP/2) uses a separate AdmServ-PHP-FPM daemon to run the separate AdmServ-PHP just for the GUI.
As before on BlueOnyx 5211R and 5210R this unshackles the OS provided PHP from the GUI and you can do with that whatever you want. It may break your Vsites PHP implementation if you upgrade PHP yourself, but the GUI will still work as it now brings its own.
The network managing and handling of BlueOnyx 5212R has been improved, Vsite creation got a little overhaul and too many fixes and tweaks to be listed have been applied to provide a better experience. Let us just look at one detail:
Vsite creation:
A BlueOnyx hosted Vsite needs a siteAdmin - especially when it also runs PHP. So during Vsite creation you are now asked for the Name, Username and Password of the siteAdmin that you want to be owner of the Vsite:
This siteAdmin is then directly created in one go and becomes owner of the /web folder and the user under whose UID/GID the PHP scripts are executed. Likewise: PHP is now by default selected as enabled for new Vsites, which also allows you to directly select the PHP version you want to use on that Vsite:
New default index.html and error pages for Vsites
When a new Vsite is created, an index.hmtl and default error pages are copied to the DocumentRoot of the newly created Vsite. These pages were still more or less in the design that stems back to the Cobalt RaQ550. This day and age? They looked ... antiquated. So we made new ones:
The new index.html not only looks more modern, but it also auto-detects the browser locale and if it is one of the supported 9 GUI languages, then the text will be auto-translated and shown in the language of the visitor.
The Vsite error pages (served out of /error/) also got a new theming and follow the general appearance of the GUI error pages:
Please note: When you import Vsites via Easy-Migrate from an older BlueOnyx and the imported Vsites still have and old style index.html and old error pages, then Easy-Migrate will replace them with the more modern versions. You can also trigger this manually on a BlueOnyx 5212R by running this script:
/usr/sausalito/sbin/update_vsite_templates.plVsite suspension:
When a BlueOnyx hosted Vsite gets suspended, then all users get their passwords invalidated so that further login is no longer possible. Processes belonging to that Vsite group are terminated and the root directory of the Vsite receives permissions which make it inaccessible for anyone but user "root".
Web access to a suspended Vsite then used to trigger a generic Apache error. While that served a purpose and has always been the way on our platform since the Cobalt days? We can do better.
The server administrator can now specify an optional "Suspension Message" when a Vsite is going to be suspended. This text field accepts text and HTML:
When someone accesses a suspened Vsite via the web, then a new error page (served out of /var/www/html/) is the only page that is being displayed. Regardless which URL on the Vsite the visitor went to.
If a "Suspension Message" was given, then this will be shown on the error page as well. This page will also auto-translate if the visitor's browser uses one of the nine supported GUI languages, although the "Suspension Message" will be shown as is and without being translated.
Vsite Over Quota handling
Whenever a Vsite uses more disk space than allocated, features of PHP, FTP and Email get disabled to prevent further growth of the used space. This can (and often will) lead to a PHP site becoming degraded and throwing errors. Sometimes this has caused that siteAdmins and even server admins went onto wild goose chases as they had not yet realized that the degradation was the result of an over-quota situation. To make this more transparent the output of PHP pages rendered on Vsites that are over-quota will receive a special header and footer:
As soon as the over-quota situation is resolved this header and footer will disappear again.
There is more, but you notice the trend: The changes and additions are simply quality-of-life improvements that are designed to make your task easier and more straightforward.
What's next?
Although BlueOnyx 5212R is now officially released, our plate is still full and these are the things that we need to tackle in the next 2-3 weeks:
- BlueOnyx 5212R Shop PKGs (some products still need a 5212R version)
- Porting all sensible improvements back to BlueOnyx 5211R and 5210R
- We will try to release some older PHP versions for BlueOnyx 5212R for better compatibility
Give BlueOnyx 5212R a try and let us know what you think!
← Return